Internet Protocol Multimedia Core Network Subsystem (IMS) is an IP-based network framework put forward by the 3rd Generation Partnership Project (3GPP), which constructs an open and flexible service environment supporting multimedia application and is capable of providing rich multimedia services for users.
In the IMS service system, a control layer is separated from a service layer. The control layer does not provide specific services and only provides necessary functions such as triggering, routing and billing etc. to the service layer. The service triggering and control function of the control layer is implemented by Call Session Control Function (CSCF). There are three types of CSCFs, namely Proxy CSCF (P-CSCF), Interrogating CSCF (I-CSCF) and Serving CSCF (S-CSCF), wherein the I-CSCF is optional. The service layer comprises a series of Application Servers (AS) which can provide specific services, wherein an AS may be an independent entity or may exist in the S-CSCF. The control layer controls service triggering according to the subscription information of a user, schedules the services on the AS and realizes the service function. The end-to-end equipment during the session is referred to as a User Equipment (UE), which is responsible for interacting with the user. There are further various of network elements for processing IMS signaling and media gateways controlled by the network elements in the IMS network, such as P-CSCF and an Access GateWay (AGW) controlled by the P-CSCF, Interworking Border Control Function (I-BCF) and the Interworking Border GateWay (I-BGW) controlled by the I-BCF, Session Border Control (SBC), Application Layer Gateway (ALG), etc. One of the functions of these network elements is to provide media forwarding and code transition functions through the media gateways controlled by the network elements respectively, to enable UEs supporting the same codec to perform direct media forwarding, and to enable UEs supporting different codec to realize media data interaction via the code transition function provided by the gateway. In order to simplify the description, in the present disclosure, the gateway equipment used for processing IMS signaling and media is referred to as an IMS Application Layer Gateway (IMS-ALG) and a Transition GateWay (TrGW).
FIG. 1 shows a flowchart of negotiating signaling for the IMS media codec according to the prior art. As shown in FIG. 1, during the media negotiation process of a terminal, the network element providing the code transition function negotiates codec information and decides to start the code transition function according to the used codec information, wherein the signaling network element IMS-ALG providing the code transition function controls two media transition gateways, one of which is TrGW1 only responsible for forwarding media data and the other one is TrGW2 responsible for executing the code transition function during the forwarding process of the media data. The flow is described as follows.
Step 101: UE1 sends a media resource request to a remote terminal, which carries the media address (including the connection address and the receiving port number) of the UE1 and the codec information supported by the UE1.
The media address and the codec information is carried in the request in a following way: for example, the connection address of the UE1 is represented by the value of the “c=” row, the receiving port number of the UE1 and the supported codec code are recorded in the “m=” row, and the information such as the name and parameters of the codec supported by the UE1 are recorded in the “a=” row of the “m=” row.
The whole content of the media resource request is carried by a message body of a message such as the invitation message (INVITE), the re-invitation message (reINVITE), the update message (UPDATE) of the IMS signaling.
Step 102: after receiving the media resource request, the IMS-ALG modifies the media address therein into the media address of the TrGW1, adds the codec information supported by the TrGW2 into the media resource request (the added codec information does not include the codec information supported by the UE1, because the codec supported by the UE1 does not need the code transition function), and then forwards the media resource request; wherein the added codec information may also be recorded in the “m=” row and the “a=” row.
Step 103: after receiving the media resource request, the UE2 uses the media address of the TrGW1 according to both the information in the media resource request and the requirements of a standard, and then uses the codec information supported by the TrGW2 according to the codec information supported by the UE2 itself (e.g. all the codecs supported by the UE1 are not supported by the UE2).
Step 104: the UE2 sends a media resource response carried with the media address of the UE2 (including connection address and the receiving port number) and the codec information used by the UE2 and the codec information supported by the UE2.
For example, the connection address of the UE2 is represented by the value of the “c=” row, the receiving port number of the UE2, and the used and supported codec codes are recorded in the “m=” row, and the information such as the name and parameters of the codec used or supported by the UE2 are recorded in the “a=” row of the “m=” row. The codec used by the UE2 is arranged in the first position of the “m=” row and the corresponding first “a=” row; the codec information supported by the UE2 is arranged in other positions of the “m=” row.
The whole content of the media resource response is carried by a message body of a message such as the approval message (200 OK) of the IMS signaling.
Step 105: after receiving the media resource response, the IMS-ALG determines that the remote terminal has used the codec supported by the TrGW2, and decides to take TrGW2 as the node of the media path, i.e. the gateway connecting to the two parts of the media.
Step 106: the IMS-ALG modifies the media address in the received media resource response into the media address of the TrGW2, and modifies the codec information used in the media resource response into the information of a certain codec supported by the UE1, e.g. a first one of codecs of the UE1 received in Step 101, and then forwards the media resource response.
So far, the media negotiation is completed for the first time. The IMS-ALG acquires the media address of the UE1 and the UE2 acquires the media address of the IMS-ALG. The UE2 can send media data to the IMS-ALG, the IMS-ALG can forward media data to the UE1, and vice versa. However, the UE1 and the UE2 cannot perform interaction of media data, because the UE2 sends the coded media data to the TrGW1, while the TrGW1 does not provide the code transition function. Therefore, after the media data forwarded by the TrGW1 arrives at the UE1, the UE1 cannot parse the correct media data.
Step 107: simultaneous with Step 106, the IMS-ALG sends a new media resource request to the UE2, which carries the media address of the TrGW2 and the codec information supported by the TrGW2 (the added codec information does not include the codec information supported by the UE1, because the codec supported by the UE1 does not need the code transition function). The whole content of the new media resource request is carried by a message body of a message such as the re-invitation message (reINVITE) and the update message (UPDATE) of the IMS signaling.
Step 108: after receiving the new media resource request, the UE2 uses the media address of the TrGW2 according to both the information in the media resource request and the required standard, and selects to use the codec information of the TrGW2 according to the codec information supported by the UE2 itself.
Step 109: the UE2 sends a media resource response carried with the media address of the UE2 and the codec information used by the UE2 and the codec information supported by the UE2. The whole content of the media resource response is carried by a message body of a message such as the approval message (200 OK) of the IMS signaling.
Until now, the UE1 and the UE2 can realize media data interaction through the media code transition and forwarding function of the TrGW2.
The current IMS media codec negotiation method needs an extra interaction of media resource request and response, which increases the signaling overhead and may result in that, after a call is connected, there still needs a certain period of time for completing the extra signaling overhead until the call is really communicated.